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[57] ABSTRACT 

Device A in a public key cryptographic network will be 
constrained to continue to faithfully practice a security 
policy dictated by a network certification center, long 
after device A's public key PUMa has been certified. If 
device A alters its operations from the limits encoded in 
its configuration vector, for example by loading a new 
configuration vector, device A will be denied participa- 
tion in the network. To accomplish this enforcement of 
the network security policy dictated by the certification 
center, it is necessary for the certification center to 
verify at the time device A requests certification of its 
public key PUMa, that device A is configured with the 
currently authorized configuration vector. Device A is 
required to transmit to the certification center a copy of 
device A*s current configuration vector, in an audit 
record, the certification center then compares device 
A's copy of the configuration vector with the autho- 
rized configuration vector for device A stored at the 
certification center. If the comparison is satisfactory, 
then the certification center will issue the requested 
certificate and will produce a digital signiture dSigPRC 
on a representation of device A's public key PUMa, 
using the certification center's private certification key 
PRC. Thereafter, if device A attempts to change its 
configuration vector, device A's privacy key PRMa 
corresponding to the certified public key PUMa, will 
automatically become unavailable for use in communi- 
cating in the network. 

24 Claims, 7 Drawing Sheets 
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FIG. 10 
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Level of Import Integrity for the Key " Ser. No. 

METHOD TO ESTABLISH AND ENFORCE A 07/602,989, filed Oct. 24, 1990, assigned to IBM Corpo- 
NETWORK CRYPTOGRAPHIC SECURITY ration and incorporated herein by reference. 

POLICY IN A PUBLIC KEY CRYPTOSYSTEM S. M. Matyas, et a!., "A Hybrid Public Key Al- 

5 gorithm/Data Encryption Algorithm Key Distribution 
BACKGROUND OF THE INVENTION Method Based on Control Vectors," Ser. No. 

1 Technical Field 07/748,407, filed Aug. 22, 1991, assigned to IBM Cor- 

The invention disclosed broadly relates to data pro- P 0 ™^ incorporated herein by reference, 
cessing systems and methods and more particularly S. M. Matyas, et al., Generating Pubhc ^d Pnvate 
relates to cryptographic systems and methods for use in 10 Key Pairs Using a Passphrase. Ser No. 07/766,533 
data processing systems to enhance security. filed Sep. 27, 1991, assigned to IBM Corporation and 

2. Background Art incorporated herein by reference. 

The following patents and patent applications are S. M. Matyas, et al.. "Public Key Cryptosystem Key 
related to this invention and are incorporated herein by Management Based on Control Vectors," Ser. No. 
reference: 15 07/766,260, filed Sep. 27, 1991, assigned to IBM Corpo- 

B. Brachtl, et al., "Controlled Use of Cryptographic ration and incorporated herein by reference. 
Keys Via Generating Stations Established Control Val- The cryptographic architecture described in the cited 
ue$," U.S. Pat. No. 4,850,017, issued Jul. 18, 1989, as- patents by S. M. Matyas, et al. is based on associating 
signed to IBM Corporation and incorporated herein by with a cryptographic key, a control vector which pro- 
reference. 20 vides the authorization for the uses of the key intended 

S. M. Matyas, et al., "Secure Management of Keys by the originator of the key. The cryptographic archi- 
ving Control Vectors," U.S. Pat. No. 4,941,176, issued tecture described in the cited patents by S. M. Matyas, 
Jul. 10, 1990, assigned to IBM Corporation and incorpo- et a j. ^ based on the Data Encryption Algorithm 
rated herein by reference. (DEA), see American National Standard X3.92-1981, 

S. M. Matyas, et al., "Data Cryptography Operations 25 0 ata Encryption Algorithm, American National Stan- 
Using Control Vectors," U.S. Pat. No. 4,918,728, issued dards i nst itute, New York (Dec. 31, 1981), whereas the 
Apr. 17, 1990, assigned to IBM Corporation and incor- pre sent invention is based on both a secret key algo- 
porated herein by reference. rithm, such as the DEA, and a public key algorithm. 

S. M. Matyas, et al., "Personal Identification Number Various key management functions, data cryptography 
Processing Using Control Vectors," U.S. Pat. No. 30 functionSj otner ^ata processing functions are possi- 

4.924.514, issued May 8, 1990, assigned to IBM Corpo- bJe usmg contro i vectors, in accordance with the inven- 
ration and incorporated herein by reference. tjQn A system administrator can exercise flexibility in 

S. M. Matyas, et al., "Secure Management of Keys ^ . lementation of his securit y policy by selecting 
Using Extended Control Vectors, US. Pat. No. riate control vectors in accordance with the 

4.924.515, issued May 8, 1990, assigned to IBM Corpo- 35 A cryptogra p hic farility (C F) in the crypto- 
ration and incorporated herein by reference. hic ^j^^ is descr ibed in the above cited 

S. M Matyas, et al., 'Secure Key M^agemenl , Using J £ M. Matyas, et al. The CF is an instruction 

fication Detection Codes Based on a Public One Way graph.c kcihty application program (CFAP) is also 
Encryption Function," U.S. Pat. No. 4,908,861 , issued described in the referenced patents and patent appl.ca- 
Mar 13 ™90, assigned to IBM Corporation and incor- tions, wh.ch defines an invocation method, as a calling 
Crated herein bv reference sequence, for each cryptographic instruction consisting 

D Abraham, et al., "Smart Card Having External 50 of an instruction mnemonic and an address with corre- 
Programming Capability and Method of Making spending input and output parameters. 
Same," Ser. No. 004,501, filed Jan. 19, 1987, assigned to Pubhc key , encryption algorithms are described in a 
IBM Corporation and incorporated herein by reference. paper by W. Diffie and M. E. Hellraan entitled "Privacy 

S.M. Matyas, "Technique for Reducing RSA Crypto and Authenticate An Introduction to Cryptogra- 
Variable Storage", U.S. Pat. No. 4,736,423, issued Apr. 55 phy," Proceeding: to/ the IEEE Volume 67, No. 3, 
5, 1988, assigned to IBM Corporation and incorporated March 1979, pp. 397-427. Pub ic key systems are based 
herein by reference on dispensing with the secret key distribution channel, 

S. M. Matyas, et' al., "Secure Management of Keys as long as the network has a sufficient level of integrity. 
Using Control Vectors with Multi-Path Checking," In a public key cryptographic system, two keys are 
Ser. No. 07/596,637, filed Oct. 12, 1990, assigned to 60 used, one for enciphering and one for deciphering. Pub- 
IBM Corporation and incorporated here by reference. He key algorithm systems are designed so that it is easy 

S. M. Matyas, et al., "Secure Cryptographic Opera- to generate a random pair of inverse keys a public key 
tions Using Alternate Modes of Control Vector En- PU for enciphering and a private key PR for decipher- 
forcement," Ser. No. 07/574,012, filed Aug. 22, 1990, ing, and it is easy to operate with PU and PR. but is 
assigned to IBM Corporation and incorporated here by 65 computationally infeasible to compute PR from PU. 
reference. Each user generates a pair of inverse transforms, PU 

S. M. Matyas, et al., "Method and Apparatus for and PR. He keeps the deciphering transformation PR 
Controlling the Use of a Public Key, Based on the secret, and makes the enciphering transformation PU 
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public by placing it in a public directory. Anyone can In the above example of DEA key distribution, 
now encrypt messages and send them to the user, but no where B sends A a DEA key K, the method is secure 
one else can decipher messages intended for him. It is only if A can be sure that K has in fact originated from 
possible, and often desirable, to encipher with PU and the party so stated (i.e., K originated from the party 
decipher with PR. For this reason. PU is usually re- 5 who has signed K or ePUa(K) or the message). Suppose 
ferred to as a public key and PR is usually referred to as that B signs K or hash(K), not ePUa(K) or hash- 
a private key. (ePUa(K)), i.e., the signature is of the form dPRb(K) or 
One important feature of a public key cryptographic dPRb(hash(K)). Suppose that the signature is of the 
system is that it provides an improved method of key form dPRb(hash(K)), so that inverting dPRb(hash(K)) 
distribution, particularly in the case of a hybrid crypto- 10 with PUb to recover hash(K) does not reveal the value 
graphic system where it is desired to distribute DEA of K. Now, if an adversary with public and private key 
keys using the public key cryptographic system. To pair (PUx,PRx) could substitute PUx for PUa, thus 
implement this key distribution feature, each user A, B, causing B to encrypt K with PUx instead of PUa, then 
etc., has an associated public and private key pair (PUa,- the adversary could defeat security by (1) intercepting 
PRa), (PUb.PRb), etc. Any user, say B, who wishes to 15 ePUx(K) and dPRb(hash(K)), (2) decrypting ePUx(K) 
distribute a DEA key K to user A, merely encrypts K with PRx, (3) re-encrypting K with PUa to produce 
with PUa, the public key of A. Since only A has PRa, ePUa(K), and (4) sending ePUa(K) and dPRb(hash(K)) 
the private key of A, only A can decrypt and recover to A. In this case, A and B are unaware that the adver- 
K. This ensures that only A (who has PRa) and the sary has had a peek at K. If B instead signs ePUa(K) or 
sender (who used PUa) have a copy of K. However, to 20 the hash of ePUa(K), then the attack still works, but is 
make this protocol secure, it is necessary for the sender a bit more complicated. However, if an adversary with 
to prove his or her identitv to A. That is, if B is the public and private key pair (PUx.PRx) could substitute 
sender, then B must prove his or her identity to A. Only PUx for PUa and PUx for PUb, thus causing B to en- 
then will A be sure that the key originated with B. crypt K with PUx instead of PUa and could cause B to 
(Note that B is already sure that only A can recover the 25 validate the signature dPRx(ePUa(K)) with PUx in- 
key.) The means to accomplish this is for B to "sign 11 K stead of PUb, then then adversary could defeat security 
• or the encrypted key ePUa(K) or the message, with his by (1) intercepting ePUx(K) and dPRb(hash(ePUx(K)), 
or her private key PRb. Messages are signed using a (2) decrypting ePUx(K) with PRx, (3) re-encrypting K 
cryptographic variable called a digital signature, as with PUa to produce ePUa(K), (4) hashing ePUa(K) to 
explained below. A method for distributing DEA keys 30 form hash(ePUa(K)), (5) decrypting hash(ePUa(K)) 
using a public key algorithm is taught in co-pending with PRx to form digital signature dPRx(hash- 
patent application Ser. No. 07/748,407, cited in the (ePUa(K))), and (6) sending ePUa(K) and dPRx(hash- 
Background Art. (ePUa(K))) to A. In this case, A validates dPRx(hash- 
A corollary feature of public key cryptographic sys- (ePUa(K))) with PUx and thus believes that ePUa(K) 
terns is the provision of a digital signature which 35 originates with B. A and B are unaware that the adver- 
uniquely identifies the sender of a message. If user A sary has had a peek at K. 

wishes to send a signed message M to user B, he oper- The methods of attack outlined above are thwarted 
ates on it with his private key PR to produce the signed by ensuring that A has a valid copy of PUb and that B 
message S. PR was used as A's deciphering key when has a valid copy of PUa. The common method for ac- 
. privacy was desired, but it is now used as his "encipher- 40 complishing this is to use a certification center which 
ing M key. When user B receives the message S, he can permits public keys to be registered with the certifica- 
recover the message M by operating on the ciphertext S tion center. The process works like this. A party, say A, 
with A's public PU. By successfully decrypting As produces a key pair (PUa.PRa). PUa is included in a 
message, the receiver B has conclusive proof it came message, often called a certificate. The certificate con- 
from the sender A. Digital signatures can be produced 45 tains a public key and key-related data such as an identi- 
either by decrypting the data to be signed with the fier of the party creating and registering the key, in this 
private key, which works well when the data is short, or case, party A, a key name, a start and end date and time 
by first hashing the data with a strong one-way crypto- when the key is active, etc. The certification center also 
graphic function and decrypting the so-produced has a key pair (PUcertPRcert), where PUcert is distrib- 
hashed value with the private key. Either method will 50 uted with integrity, in advance, to each of the other 
work. Thus, in the above described method of DEA parties in the network serviced by the certification cen- 
key distribution, B sends A two quantities: (1) the en- ter, i.e., to A, B, C, etc. After the certification center is 
crypted key, ePU(K), and (2) a digital signature e.g., of satisfied that a request for public key registration is 
the form (a) dPR(ePU(K)) or dPR(hash(ePU(K))). A "okay" (e.g., that party A is in fact the actual party to 
method for producing digital signatures based on the 55 whom the to-be-registered public key belongs), then the 
hash of the data to be signed is taught in co-pending certification center signs the certificate with its private 
patent application Ser. No. 07/748,407, cited in the key PRcert, i.e., the cryptographic quantity dPRccrt- 
Background Art. Examples of public key cryptography (hash(certificate)) is produced, and the certificate and 
are provided in the following U.S. patents: U.S. Pat. digital signature are returned to party A or stored in a 
No. 4,218,582 to Hellman, et al. t "Public Key Crypto- 60 central directory. Thereafter, the certificate and digital 
graphic Apparatus and Method;" U.S. Pat. No. signature can be used as proof that PUa belongs to party 
4,200,770 to Hellman, etal., "Cryptographic Apparatus A. For example, party B obtains the certificate and 
and Method;" and U.S. Pat. No. 4,405,829 to Rivest, et digital signature from party A or from the central direc- 
al., "Cryptographic Communications System and tory and validates the signature with PUcert, the public 
Method." The signature is prepared by operating on it 65 key of the certification center. This proves to B that 
with the private key PR. Although this operation is PUa belongs to A. In like manner, A can obtain and 
referred to as "encrypting" herein, since PR is secret, authenticate a digital signature and certificate contain- 
some writers describe this operation as "decrypting." ing B*s public key PUb. This completely thwarts the 
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above attacks wherein an adversary substitutes one establishes a key-distribution channel with at least one 
public key for another, thereby causing A to use PUx other network device. When key distribution is per- 
instead of PUb and causing 8 to use PUx instead of formed in a peer-to-peer environment, each device is 
pT j a initialized with a key-encrypting key for each other 

In most cryptographic systems, the keys belonging to 5 device with which it wishes to communicate. However, 
a cryptographic device are encrypted with a single when key distribution is performed with the assistance 
master key and stored in a cryptographic key data set. of a key-distribution center (KDC) or key-translation 
The master key is stored in clear form within the cryp- center (KTC), each device is initialized with only one 
tographic hardware. The concept of using a single mas- key-encrypting key shared with the KDC or MU 
ter key to encrypt keys stored in a cryptographic key 10 Thereafter, additional key-encrypting keys are distno- 
data set is known as the master key concept. In order to uted electronically and initialized automatically using 
electronically distribute keys from one device to an- the KDC or KTC. The key-distribution channel can 
other, e.g., to distribute a data-encrypting key as part of also be made unidirectional. That is, one key-encrypting 
session initiation, each pair of devices shares a unique key encrypts keys transmitted from a first device to a 
key-encrypting key under which all distributed keys are 15 second device and another key-encrypting key encrypts 
encrypted. Thus, a data-encrypting key encrypts many keys transmitted in the other direction. As stated above, 
messages. A key-encrypting key encrypts many dec- each cryptographic device is initialized with at least one 
tronically distributed data-encrypting keys, and so key-encrypting key. Consider the process of installing 
forth. A master key encrypts many key-encrypting and keys between two devices A and B, where one device, 
data-encrypting keys stored in a particular system's 20 say A, generates a key-encryptmg key for installation at 
cryptographic key data set. Key management design both A and B. At device A, a clear key- encrypting key 
principles are discussed in a paper by S. M. Matyas, et KK is randomly generated, e.g., by com tossing. The 
al entitled "A Key-Management Scheme Based on clear KK is then manually loaded into the crypto- 
Control Vectors/* IBM Systems Journal, Volume 30, graphic hardware where it is encrypted under the A s 
No 2 1991 pp 175-191 25 master key, or a variant key formed as the Exclusive- 

Most cryptographic systems make use of many differ- OR product of the master key and a control vector. The 
ent types of keys, so that information encrypted with a encrypted value of KK is then stored in As crypto- 
key of one type is not affected by using a key of another graphic key data set. The clear value of KK is then 
type A key is assigned a type on the basis of the infor- transported to device B, e.g., using a courier. At device 
mation the key encrypts or the use being made of the 30 B, KK is manually loaded into the cryptographic hard- 
key. For example, a data-encrypting key encrypts data. ware where it is encrypted under B's master key, or a 
A key-encrypting key encrypts keys. A PIN-encrypting variant key formed as the Exclusive-OR product of he 
key encrypts personal identification numbers (PINs) master key and a control vector. The encrypted value 
used in electronic funds transfer and point-of-sale appli- of KK is then stored in B's cryptographic key data set 
cations A MAC key is used to generate and authenti- 35 The encrypted copies of KK at A and B enable A and 
cate message authentication codes (MACs). B to communicate cryptographically as described in 

At the time a key is generated, the user or user appli- U.S. Pat. No 4,94 l,m U.S. Pat. No. 4.94U76 also 
cation determines, from among the range of options provides for the initial key-encrypting key KK to be 
permitted by the key management, the form of each defined as the Exclusive-OR product of two or more 
generated key. For example, a generated key can be 40 key parts. At device A, each key part is manual y 
produced (1) in clear form, (2) in encrypted form suit- loaded into the cryptographic hardware The separately 
able for storage in a cryptographic key data set, or (3) in entered key parts are combined within the hardware to 
encrypted form suitable for distribution to a designated form the final value of KK. Each key part can be trans- 
receiving device. Generally, cryptographic systems ported to the receiving cryptographic device using a 
have different options for generating keys in these dif- 45 separate courier. At device B, each key part is manually 
ferent forms. Key types also include a device key pair loaded into the cryptographic hardware and combined 
used for backup and recovery purposes. Also, at the to form the final value of KK. 
time a key is generated, the user or user application In a hybrid cryptographic system, the key manage- 
determines, from among the range of options permitted ment is designed so that DEA keys are distributed 
by the key management, the type and usage of each 50 under the encryption of a public key. That is, B distnb- 
generated key Type and usage information are exam- utes a key to A by encrypting the key under PUa, A's 
pies of a class of key-related information called control public key. A recovers the key by decrypting the re- 
information. For example, in U.S. Pat. Nos. 4,850,017, ceived encrypted key with PRa, A's private key as 
4 941 176 4,918,728, 4,924,514, 4,924,515, and described above. Thus, the key-encryptmg key or keys 
5007 089! the control information is embodied within a 55 manually installed into the cryptographic devices of a 
data variable called the control vector. The control DEA-based cryptographic system can now be electron- 
vector concepts taught in these U.S. Patents are surama- ically distributed using a public key algorithm, 
rized in a paper by S. M. Matyas entitled "Key Han- Instead of manually installing a public and private 
dling With Control Vectors," IBM Systems Journal key pair (PU.PR) at each device, (PU,PR) is generated 
Volume 30 No. 2, 1991, pp. 151-174. In the case of the 60 inside the cryptographic device. The private key, PR, is 
device key pair, the control information associated with stored within the cryptographic hardware or it is en- 
the PU and PR keys is also stored with the keys within crypted under a master key and stored in a crypto- 
the CF, where its integrity is ensured. graphic key data set. If the public key is to be used for 

In order for a DEA-based cryptographic system to be key distribution purposes, then its integrity within the 
made operable, each device must first be initialized with 65 cryptographic network can be assured by registering it 
a master key and at least one key-encrypting key. The at a certification center and receiving a certificate and 
master key permits keys stored in the cryptographic key digital signature, as described above. This allows the 
data set to be encrypted,, and the key-encrypting key cryptographic device to freely distnbute the public key 
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to other devices with the assurance that the other de- 
vices will accept the public key as genuine. Thus, the 
keys used with the public key algorithm are handled 
automatically using electronic means; there is no re- 
quirement for manual installation of these keys at the 
cryptographic devices within the network. 

In some cases, the public and private keys belonging 
to a cryptographic device may be stored in clear form 
within the cryptographic hardware. As an alternative to 
this approach, keys may be stored outside the crypto- 
graphic hardware, e.g., encrypting the public and pri- 
vate keys with the master key, or a variant key derived 
from the master key, and storing them in key tokens 
together with other key-related data (i.e., a control 
vector), as described in co-pending patent application 
Ser. No. 07/766,260 entitled "Public Key Cryptosystem 
Key Management Based on Control Vectors." Thus, 
the prior art describes how, in a hybrid cryptographic 
system using a public key algorithm, to eliminate (1) 
couriers and (2) manual entry of clear key-encrypting 
. keys. While this is an improvement over a DEA-based 
cryptographic system, the prior art does not teach how 
to eliminate a requirement for manual entry of clear 
keys altogether. Except in special situations, each cryp- 
tographic device will need several, and perhaps many, 
key pairs to perform the tasks of key management and 
data management. And, the most practical means for 
doing this is to make use of a system master key under 
which, at least, the private keys of the public key algo- 
rithm are encrypted for storage in a cryptographic key 
data set. It is also argued in co-pending patent applica- 
tion Ser. No. 07/766,260 that it is sometimes advanta- 
geous to encrypt the public keys for storage in a crypto- 
graphic key data set, even though this is not done to 
keep the public keys secret. Thus, it would be advanta- 
geous for the cryptographic system key management to 
be designed so that the need for manual entry of keys, 
including the master key itself, is completely eliminated. 
This would permit cryptographic systems to be used in 
places where it is impractical or infeasible for a secret 
master key to be manually loaded into the crypto- 
graphic device. In so doing, cryptographic systems 
could now be designed so that their initialization is fully 
automated, i.e., not requiring couriers and not requiring 
the manual entry of keys by humans. 

Also note that if all manual entry of keys could be 
eliminated, this would allow a potential higher level of 
security to be established for the system, as no human, 
authorized or not, would be able to introduce known 
key values into the system which, if entered, would 
allow the possibility of off-line decryption of anything 
encrypted under the known quantity. 

In many cryptographic systems, such as described in 
U.S. Pat. Nos. 4,850,017, 4,941,176, 4,918,728, 
4,924,514, 4,924,515, and 5,007,089, and co-pending 
patent application Ser. No. 07/766,260, the crypto- 
graphic hardware is initialized with configuration data 
as well as other cryptographic variables, including keys, 
such as the master key. The configuration data person- 
alizes a device, e.g., uniquely identifies a device and 
restricts the processing options that the device is per- 
mitted to perform, including the possibility of crippling 
the ability to manually enter keys. 

As was discussed above, the conventional operation 
of a network using a certification center enables each 
recipient of a certified public key PUMa from device A, 
for example, to be assured of the genuineness of that 
key. The certificate and digital signature dSigPRC is- 
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sued by the certification center on that key PUMa can 
be used by device B, for example, as proof that the key 
PUMa belongs to device A. Device B merely decodes 
the digital signature dSigPRC with its copy of the certi- 

5 fication center's public key PUC, to validate PUMa. 
Device B is then sure that when he encrypts his secret 
messages under device A*s certified public key PUMa, 
that key belongs to device A. Device A then decodes 
the encrypted message using device A's private key 

10 PRMa. However, there is no assurance that device A's 
private key PRMa has not been compromised. Device 
A's security practices may have become lax either prior 
to or after the event of certification of PUMa by the 
certification center. Device B may be entrusting its 

15 valuable secret information to device A f s compromised 
system, enabling an adversary to discover device B's 
information. Any network security policy initially es- 
tablished and implemented by configuration data loaded 
into member devices in a network, can be deviated from 

20 by one device in the network, thereby compromising 
the secret information transmitted to that deviant de- 
vice by other devices in the network. 

The prior art has not provided an adequate means to 
require member devices in a network to be constrained 
to continue faithfully practicing an established network 
security policy. 

OBJECTS OF THE INVENTION 

30 It is therefore an object of the invention to provide an 
improved method of key management in a public key 
cryptographic system. 

It is another object of the invention to provide an 
improved method of key management in a public key 

35 cryptographic system which promulgates, implements 
and enforces a network security policy. 

It is another object of the invention to provide an 
improved method of key management in a public key 
cryptographic system which inhibits the participation 
by members of a network who have deviated from 
compliance with an established network security pol- 
icy. 

It is another object of the invention to provide an 
improved method of key management in a public key 
45 cryptographic system, which can enforce a network 
security policy for diverse levels of security to be imple- 
mented among the several client devices in the network. 

SUMMARY OF THE INVENTION 

These and other objects, features, and advantages arc 
accomplished by the invention disclosed herein. A net- 
work is configured so that a first data processor pro- 
vides a certification center function for the network. A 
second data processor in the network functions as client 
device A, which will seek certification of its public keys 
by the certification center. A third data processor in the 
network functions as client device B, which will seek 
certification of its public keys by the certification cen- 
ter. In accordance with the invention, the certification 
center will encode the network security policy into a 
configuration vector which is transmitted to each client 
device A and B in the network. The network security 
policy may provide for diverse levels of security to be 
implemented among the several client devices in the 
network. The configuration vector received by a client 
device, for example client device A, is decoded and 
used to configure its cryptographic system so that its 
operations are limited so as to maintain its level of secu- 
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rity in compliance with the network security policy BRIEF DESCRIPTION OF THE DRAWINGS 

dictated by the certification center. „ a . , . . ..„„,„„„ _r 

As was discussed in the background herein, the con- ™ese and other objects, fea 

ventional operation of a network using a certification the ^^^^ X re T 

center, enables each recipient of a certify public key * «g £ network includ - 

PUMa from device A. for example, to be assured of the Qf ^ s$orSj ^ of which m . 

genuineness of that key, that is the certificate and digital [ ^ ysttm . 

signature dSigPRC issued by the certification center on plG 2 fe fl blQck diagram of a cryptographic system 

that key PUMa can be used by device B, for example, as JQ 22 

proof that that key PUMa belongs to device A. Device p IG 3 - s a block diagram of a cryptographic facility 

B merely decodes the digital signature dSigPRC with 30 

its copy of the certification center's public key PUC, to p IG 4 illustrates a portion of the cryptographic facil- 

validate PUMa. ity environment memory in the client device A. 

However, in accordance with the invention, device 15 FIG. 5 illustrates a portion of the cryptographic facil- 

A, in this example, will be constrained to continue faith- j ty environment memory in the certification center 10. 

fully practicing the security policy dictated by the certi- FIG. 6 is an example format for a portion of a config- 

fication center, long after device A's public key PUMa uration vector 161. 

has been certified. If device A alters its operations from FIG. 7 is an example of the information transmitted 
the limits encoded in its configuration vector, for exam- 20 from device A to the certification center, requesting 

pie by loading a new configuration vector, device A certification of public key PUMa. 

will be denied participation in the network. In accor- FIG. 8 is an example of a public key «rtfi"tcfor 

die J£ the invention, to accomplish this enforce- PUMa, accompanied by the certification center s digital 

ment oT tne network security policy dictated by the ^^S^t " 

certification center it is necessary for » «^ program ^ 

center to verify at the time device A requests certifica- *^ ^ ^ 
tion of its public key PUMa, that device A is configured 

with the currently authorized configuration vector. piG. 10 is a flow diagram of a computer program and 
Device A is required to transmit to the certification 3Q method execute d in the certification center 10, to en- 
center a copy of device A's current configuration vec- fofce network seC arity policy. 

tor, in an audit record. The certification center then pj G u j s a fl ow diagram of a computer program and 

compares device A's copy of the configuration vector met hod executed in device A to perform key manage- 

with the authorized configuration vector for device A mem f unct i 0 ns in the run state. 

stored at the certification center. If the comparison is 35 piG. 12 is a flow diagram of a computer program and 

satisfactory, then the certification center will issue the method executed in device A to change the configura- 

requested certificate and will produce a digital signa- t j on vector. 

ture dSigPRC on a representation of device A's public DESCRIPTION OF THE BEST MODE FOR 

key PUMa, using the certification center s private certi- " CARRYING OUT THE INVENTION 

fiC From that time on, device A can distribute its certi- FIG. 1 illustrates a network block diagram showing a 
fied public key PUMa to other devices, such as device communications network connecting a plurality of data 
B, and device A can receive messages encrypted under processors including data processor 20 data processor 
it public key PUMa, which it can decrypt under device 20', and data processor 20''. Also « d <**^ *» 
A's paired private key PRMa. And device A can sign its 45 processor is a cryptographic system, as shown in FIG 
e\ s pmrcu pnvaiw iwcjr * *™ » - D nrocessor 20 in eludes cryptograph ic system 22, 
messages to other devices in the network, such as to cryptographic system 22* 
device B, by signing with Jj d ^~ i, *r includ^cryptoVaphic system 
RMa using device A's private key » d ^ 22". Each data processor supports the processing of one 
ient device B will validate the message by decrypting * ^ ^^"require access to crypto- 
dSigPRMa using its copy of device A s certified public ^ ^ for ^ encryption| decryption 
key PUMa. _ t m ^ authenticating of application data and the genera- 
However, in accordance with the invention, device ^ ^ installation of cry ptographic keys. The crypto- 
A can have use of its private key PRMa only so long as graphic serv ices are provided by a secure crypto-, 
device A adheres to the network security policy by 5J grapnic f ac uity in each cryptographic system. The net- 
preserving its authorized copy of the configuration wor k pr0 vides the means for the data processors to send 
vector in its cryptographic system. In accordance with and rccc j vc encrypted data and keys. Various proto- 
the invention, if a new configuration vector replaces the colSj ^ f orma ts and procedural rules, govern the 
authorized copy in device A*s cryptographic system, exchange of cryptographic quantities between commu- 
then the cryptographic system automatically denies gQ Seating data processors in order to ensure the interop- 
device A the use of its private key PRMa. This results in erability between them. 

device A being incapable of signing outgoing messages The network of FIG. 1 is configured so that the data 

with its digital signature dSigPRMa and incapable of processor 20 provides a certification center 10 function 

decrypting incoming messages encrypted by the sender for the network. Data processor 20' functions as client 
under device A's certified public key PUMa. 65 device A 12, which will seek certification of its public 

In this manner, the network security policy promul- keys by the certification center 10 over line 21. Data 

eated by the certification center is implemented and processor 20" functions as client device B 1* which will 

enforced seek certification of its public keys by the certification 
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center 10 over line 23. In accordance with the inven- cryptographic system automatically denies device A 

tion, the certification center 10 will encode the network the use of its private key PRMa. This results in device A 

security policy into a configuration vector which is being incapable of signing outgoing messages with its 

transmitted to each client device A and B in the net- digital signature dSigPRMa and incapable of decrypt- 

work.. The network security policy may provide for 5 ing incoming messages encrypted by the sender under 

diverse levels of security to be implemented among the device A's certified public key PUMa. 

several client devices in the network. The configuration In this manner, the network security policy promul- 

vector received by a client device, for example client gated by the certification center is implemented and 

device A, is decoded and used to configure its crypto- enforced. 

graphic system 22' so that its operations are limited so as 10 FIG. 2 illustrates the cryptographic system 22. In the 
to maintain its level of security in compliance with the cryptographic system 22, the cryptographic facility 
network security policy dictated by the certification . (CF) 30 has an input 37 from a physical interface. The 
center 10, cryptographic facility access program (CFAP) 34 is 
As was discussed in the background herein, the con- coupled to the cryptographic facility 30 by means of the 
ventional operation of a network using a certification 15 interface 31. The cryptographic key data set (CKDS) 32 
center, such as certification center 10 in FIG. 1, enables is connected to the cryptographic facility access pro- 
each recipient of a certified public key PUMa from gram 34 by means of the interface 33. The application 
device A, for example, to be assured of the genuineness programs (APPL) 36 are connected to the crypto- 
of that key. The certificate and digital signature graphic facility access program 34 by means of the 
dSigPRC issued by the certification center 10 on that 20 interface 35. 

key PUMa can be used by device B, for example, as A typical request for cryptographic service is initi- 

proof that that key PUMa belongs to device A. Device ated by APPL 36 via a function call to the CFAP 34 at 

B merely decodes the digital signature dSigPRC with the interface 35. The service request includes key and 

his copy of the certification center's public key PUC, to data parameters, as well as key identifiers which the 

validate PUMa. . 25 CFAP 34 uses to access encrypted keys from the 

However, in accordance with the invention, device CKDS 32 at the interface 33. The CFAP 34 processes 

A, in this example, will be constrained to continue faith- the service request by issuing one or more crypto- 
fully practicing the security policy dictated by the certi- graphic access instructions to the CF 30 at the interface 
fication center 10, long after device A's public key 31. The CF 30 may also have an optional physical inter- 
PUMa has been certified. If device A alters its opera- 30 face 37 for direct entry of cryptographic variables into 
tions from the limits encoded in its configuration vec- the CF 30. Each cryptographic access instruction in- 
tor, for example by loading a new configuration vector, voked at the interface 31 has a set of input parameters 
device A will be denied participation in the network. In processed by the CF 30 to produce a set of output pa- 
accordance with the invention, to accomplish this en- rameters returned by the CF 30 to the CFAP 34. In 
forcement of the network security policy dictated by 35 turn, the CFAP 34 may return output parameters to the 
the certification center, it is necessary for the certifica- APPL 36. The CFAP 34 may also use the output pa- 
tion center to verify at the time device A requests certi- rameters and input parameters to subsequently invoke 
fication of its public key PUMa, that device A is config- instructions. If the output parameters contain encrypted 
ured with the currently authorized configuration vec- keys, then the CFAP 34, in many cases, may store these 
tor. Device A is required to transmit to the certification 40 encrypted keys in the CKDS 32. 

center a copy of device A's current configuration vec- FIG. 3 illustrates the cryptographic facility 30. The 

tor, in an audit record. The certification center then cryptographic facility 30 is maintained within a secure 

compares device A's copy of the configuration vector boundary 140. The cryptographic facility 30 includes 

with the authorized configuration vector for device A the instruction processor 142 which is coupled to the 

stored at the certification center. If the comparison is 45 cryptographic algorithms 144 which are embodied as 

satisfactory, then the certification center will issue the executable code. The cryptographic facility environ- 

requested certificate and will produce a digital signa- ment memory 146 is coupled to the instruction proces- 

ture dSigPRC on a representation of device A's public sor 142. The physical interface can be coupled over line 

key PUMa, using the certification center's private certi- 37 to the CF environment memory 146, as shown in the 

fication key PRC. 50 figure. The instruction processor 142 is coupled to the 

From that time on, device A can distribute its certi- cryptographic facility access program (CFAP) 34 by 

fied public key PUMa to other devices, such as device means of the interface at 31. 

B, and device A can receive messages encrypted under The instruction processor 142 is a functional element 
its public key PUMa, which it can decrypt under device which executes cryptographic microinstructions in- 
A's paired private key PRMa. And device A can sign its 55 voked by the CFAP access instruction at the interface 
messages to other devices in the network, such as to 31. For each access instruction, the interface 31 first 
device B, by signing with its digital signature dSigP- defines an instruction mnemonic or operation code used 
RMa using device A's private key PRMa, and the recip- to select particular microinstructions for execution, 
ient device B will validate the message by decrypting Secondly, a set of input parameters is passed from the 
dSigPRMa using its copy of device A's certified public 60 CFAP 34 to the CF 30. Thirdly, a set of output parame- 
key PUMa. ters is returned by the CF 30 to the CFAP 34. The 

However, in accordance with the invention, device instruction processor 142 executes the selected instruc- 

A can have use of its private key PRMa only so long as tion by performing an instruction specific sequence of 

device A adheres to the network security policy by cryptographic processing steps embodied as microin- 

preserving its authorized copy the configuration vector 65 structions stored in cryptographic microinstruction 

in its cryptographic system 22'. In accordance with the memory 144. The control flow and subsequent output 

invention, if a new configuration vector replaces the of the cryptographic processing steps depend on the 

authorized copy in the cryptographic system, then the values of the input parameters and the contents of the 
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CF environment memory 146. The CF environment uon-specified value via execution of the Load Configu- 
memory 146 consists of a set of cryptographic variables, ration Vector (LCV) instruction. Details of the configu- 
for example keys, flags, counters, . CF configuration ration vector, the EIS instruction and the LCV instruc- 
data, etc., which are collectively stored within the CF tion are described in the copending patent application 
30. The CF environment variables in memory 146 arc 5 by S. M. Matyas, et al., "Public Key Cryptosystem Key 
initialized via the interface 31, that is by execution of Management Based on Control Vectors," Sex. No. 
certain CF microinstructions which read input parame- 07/766,260, filed Sep. 27, 1991, assigned to IBM Corpo- 
ters and load them into the CF environment memory ration and incorporated herein by reference. 
146. Alternately, initialization can be done via an op- The Load Configuration Vector (LCV) instruction 
tional physical interface which permits cryptographic 10 permits a 64 byte configuration vector to be loaded and 
variables to be loaded directly into the CF environment stored within the CF Environment. Execution of the 
memory 146, for example, via an attached key entry LCV instruction causes the LCV FLAG to be set to the 
d ev j ce . "full" state. The LCV instruction executes only when 

The physical embodiment of the cryptographic facil- the LCV FLAG is in the "empty" state. The LCV 
ity secure boundary 140, incorporates the following 15 FLAG can only be reset to the "empty" state via execu- 
physical security features. The physical embodiment tion of an EPS or EIS instruction. In effect, the LCV 
resists probing by an insider adversary who has limited FLAG controls LCV execution as follows: (a) If the 
access to the cryptographic facility 30. The term *iim- LCV FLAG = "empty" state, then LCV instruction 
ited" is measured in minutes or hours as opposed to days execution is enabled for one execution only, whereas (b) 
or weeks. The adversary is constrained to a probing 20 if the LCV FLAG = "full" state, then LCV instruction 
attack at the customer's site using limited electronic execution is disabled. Execution of the EIS instruction 
devices as opposed to a laboratory attack launched at a causes a configuration vector in the CF Environment to 
site under the control of the adversary using sophisti- be initialized/reinitialized to a "default" value. This 
cated electronic and mechanical equipment. The physi- value can be changed by executing an LCV instruction, 
cal embodiment also detects attempts at physical prob- 25 The LCV instruction executes only in the "init" state, 
ing or intruding, through the use of a variety of electro- For reasons of security, the LCV instruction is ar- 
mechanical sensing devices. Also, the physical embodi- chitected such that the configuration vector value 
ment of the cryptographic facility 30 provides for the stored in the CF Environment cannot be changed with- 
zeroization of all internally stored secret cryptographic out erasing or invalidating the contents of the master 
variables. Such zeroization is done automatically when- 30 key KM register 151. In an alternate embodiment, the 
ever an attempted probing or intrusion has been de- private authentication key PRAa 154 or the private key 
tected. The physical embodiment also provides a man- PRMa can be erased or invalidated in response to exe- 
ual facility for a zeroization of internally stored secret cuting the LCV instruction. 

cryptographic variables. Reference to the Abraham, et The Enter Init State (EIS) instruction loads a "de- 
al, patent application cited above, will give an example 35 fault" configuration vector into the CF environment 
of how such physical security features can be imple- and resets certain flags in the state vector to change the 
mented state of the CF and to clear certain registers and buffers. 

FIG. 4 illustrates a portion of the cryptographic facil- More particularly, the Enter Init State instruction 
ity environment memory in the client device A. The CF causes the flags controlling the old, current, and new 
Environment Memory 146' in Client Device A 12 in- 40 master key registers to be reset to the "empty" state, 
eludes Master Key Register(s) 151, PUAa Public Au- thereby causing these keys to be invalid. It causes the 
thentication Key 153, PRAa Private Authentication LCV FLAG to be reset to the "empty" state, thereby 
Key 154, PUC Public Certification Center Key 157, enabling execution of the LCV instruction. It causes the 
Logical Device IDa 119, Configuration Vector(a) 161, CF STATE to be reset to the "init" state. The EIS 
and State Vector(a) 163. PRAa can also be referred to 45 instruction can be executed in the "preinit " "ink" and 
as the "private device authentication key" and PUAa "run" states, 

can also be referred to as the "public device authentica- The Enter Preinit State (EPS) instruction resets the 
tion key." C p STATE to the **preinif state; it resets the configu- 

FIG. 5 illustrates a portion of the cryptographic facil- ration and state vectors to zero and it executes algo- 
ity environment memory in the certification center 10. 50 rithm Initialize Pseudo-random Number to (further) 
The CF Environment Memory 146 in Certification initialize the pseudorandom number generator. 
Center 10 includes Master Key Registers) 151, PUC FIG. 7 is an example of the information transmitted 
Public Certification Center Key 157, PRC Private Cer- from device A to the certification center, requesting 
tification Center Key 159, Logical Device ID 119, and certification of public key PUMa. In the preferred em- 
table 155 which includes IDa, PUAa and Configuration 55 bodiment shown in FIG. 7, the information is transmit- 
Vector(a) for device A and IDb, PUAb and Configure- ted from device A to the certification center in two 
tion Vector(b) for device B. , messages, the request 168 and the audit record 170 with 

FIG. 6 is an example format for a portion of a config- its digital signature 172. In step 316 of the flow diagram 
uration vector 161. The Configuration Vector 161 in- of FIG. 9, the certification request 168 is transmitted, 
eludes a Master Key Generation Method Definition, a 60 which includes the public key PUMa 175, the identifica- 
Cryptographic Instructions Definition Bit Mask, a Key tion of device A 119, a control vector 176 for PUMa, 
Management Protocol Definition, a CF Backup Proto- and other control information 177'. The other control 
col Definition, and Other Crypto Facility Definitions. information 177' may optionally include an indication of 
The configuration vector is a collection of encoded the level of security of device A, as represented by the 
fields that limit or restrict the operation of the crypto- 65 configuration vector 161 stored at device A. In step 320 
graphic facility. The configuration vector is set to a of the flow diagram of FIG. 9, the audit record 170 and 
default value via execution of the Enter Initialization its digital signature 172 are transmitted. Device A*s 
State (EIS) instruction, or it may be set to an installa- digital signature dSigPRAa 172 on the audit record 170 
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uses device A*s private authentication key PRAa. The 
audit record 170 includes the configuration vector 161 
copied from the CF environment memory 146' of de- 
vice A, a random number nonce 171 sent from the certi- 
fication center, and the identification IDa 119 of device 5 
A. This information can be referred to as the argument 
of the audit record. Accompanying the audit record is 
the digital signature dSigPRAa of a representation of 
the argument of the audit record, computed using the 
private authentication key PRAa of device A. The 10 
representation of the argument upon which the digital 
signature is computed can be the entire argument or it 
can be a hash value of the entire argument. Digital 
signatures are computed using the Generate Digital 
Signature (GDS) instruction. Details of the Generate 15 
Digital Signature (GDS) instruction, the Crypto Facil- 
ity Audit Record (CFAR) 170 and the Export Crypto 
Facility Audit Record (ECFAR) instruction are de- 
scribed in the copending patent application by S. M. 
Matyas, et al., "Public Key Cryptosystem Key Manage- 20 
ment Based on Control Vectors." Ser. No. 07/766,260, 
filed Sep. 27, 1991, assigned to IBM Corporation and 
incorporated herein by reference. 

The Crypto Facility Audit Record (CFAR) 170 con- 
tains the nonsecret part of the CF Environment plus 25 
additional nonsecret information. The CFAR is de- 
signed to be a multiple of 8 bytes. The Crypto Facility 
Audit Record 170 includes a header and a nonsecret 
pan. The Header (H) contains information necessary to 
parse the CFAR. It also contains a random number 30 
(RN) field and a date and time (DT) field. The Header 
is 64 bytes in length. The Nonsecret Part (NSP) con- 
tains the nonsecret part of the CF Environment. NSP is 
variable length, but must be a whole number of bytes. 
The NSP in the CFAR is not the same as the NSP in the 35 
CFER (Crypto Facility Environment Record). 

RN is an eight byte CFAP-supplied time-variant 
parameter. This field is set by the ECFAR instruction 
only when process-mode =1 or process-mode ==2. This 
field is intended to be used as a nonce in a request/re- 40 
sponse protocol to guarantee freshness of the Audit 
record. The Certification Center generates a random 
number and sends it to the device to be audited in the 
Request-for-Audit message. The device then supplies 
this random number to the Export Cryptographic Facil- 45 
ity Audit Record (ECFAR) instruction. This results in 
the signed Audit record being sent to the Certification 
Center by the Audited device with the correct nonce. 
The Certification Center is assured that the Audit re- 
cord is current. 50 

The Nonsecret Part includes the following: the de- 
vice ID, the Nonsecret Part of CF Environment, the 
Configuration Vector, the State Vector, and the con- 
tents of Registers, and Tables. No encrypted informa- 
tion in the CFER ever appears in the clear in the 55 
CFAR. 

The Export Crypto Facility Audit Record instruc- 
tion constructs a Crypto Facility Audit Record 
(CFAR) and returns it to the CFAP. The CFAR con- 
tains (1) a copy of the nonsecret part of the CF Environ- €0 
ment, a date and time (DT) supplied by the CF, and (3) 
for process-mode = 1 and process-mode =2, a CFAP- 
supplied time-variant value RN. RN can be a random 
number, sequence number, or time stamp, which may be 
used by a designated receiving device to ensure that a 65 
produced CFAR is current. A process-mode parameter 
specifies to the instruction whether a digital signature is 
generated on the CFAR and, if so, then whether the 
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private key is (1) PRA or (2) a PR supplied to the 
ECFAR instruction. A hash-rule parameter indicates to 
the ECFAR instruction the hash algorithm to be used in 
generating the digital signature. Process-mode = 1 can 
only be executed when the GDAK FLAG is in the 
"full" state. Process-mode =2 can only be executed 
when the CKMP FLAG is in the "full" state. The Ex- 
port Crypto Facility Audit Record instruction executes 
in the "preinit," "init," and "run" states. 

In the preferred embodiment of the invention, the 
request made by device A for certification of its public 
key PUMa is done by sending PUMa 175, IDa 119, the 
control vector CV 176, and other information 177' with 
the request 168 in a first transmission to the certification 
center, this transmission being followed by the return of 
a random number nonce 171 from the certification cen- 
ter, which is then followed by a second transmission 
from device A of the audit record 170 and its digital 
signature 172. In an alternate embodiment of the inven- 
tion, a single transmission can take place from device A 
to the certification center, sending PUMa 175, control 
vector CV 176, configuration vector 161, IDa 119 and 
other information 177', accompanied by a digital signa- 
ture dSigPRAa of a representation of this argument 
using the private authentication key PRAa of device A. 

FIG. 8 is an example of a public key certificate for 
PUMa, accompanied by the certification center's digital 
signature dSigPRC using the certification center's pri- 
vate certification key PRC. The PUMa certificate 174 
includes the public key PUMa 175 of device A which 
has been certified, the identification IDa 119 of the 
device A, the control vector 176 for PUMa, and other 
control information 177, which can include an indica- 
tion of the level of security for device A, as verified by 
the certification center when it inspects device A*s con- 
figuration vector 161. This information can be referred 
to as the argument of the certificate. Also included as a 
part of the certificate is the digital signature dSigPRC 
178 of a representation of the argument of the certifi- 
cate, computed using the private certification key PRC 
of the certification center. The representation of the 
argument upon which the digital signature is computed 
can be the entire argument or it can be a hash value of 
the entire argument. Digital signatures are computed 
using the Generate Digital Signature (GDS) instruc- 
tion. Details of the Generate Digital Signature (GDS) 
instruction are described in the copending patent appli- 
cation by S. M. Matyas, et al., "Public Key Cryptosys- 
tem Key Management Based on Control Vectors," Ser. 
No. 07/766,260, filed Sep. 27, 1991, assigned to IBM 
Corporation and incorporated herein by reference. The 
other control information 177' in request 168 of FIG. 7 
is not necessarily the same as the other control informa- 
tion 177 in the certificate 174 of FIG. 8. 

The Generate Digital Signature instruction generates 
a digital signature, called dsig, from a Crypto Facility 
System Signature Record (CFSSR) in accordance with 
Section 6 of ISO DIS 9796. The CFSSR is a CF- 
generated record containing a 128-bit hash value calcu- 
lated on a variable length input data record, called data. 
The length of CFSSR must be less than or equal to 1/2 
the modulus length of the public key algorithm. The 
process of producing dSig from CFSSR consists of 
pre-processing steps, decryption with a private key, and 
post-processing steps. A PR-mode parameter specifies 
to the GDS instruction whether the PR key used to 
produce the system signature is specified in DCU1 (PR- 
modc=0) or whether the PR key used to produce the 
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system signature is the PRA key stored in the CF (PR- (GDAK) instruction which is described in the cop«ri- 
mode = l). A private certification key can be specified ing patent application by S. M. Matyas, et al., ?™> Uc 
to the GDS instruction only when the device is config- Key Cryptosystem Key Management Based on Control 
ured as a certification center (CERTIFICATION field Vectors," Ser. No. 07/766,260. filed Sep. 27 1991, as- 
in the configuration vector is BT). A private authentic 5 signed to IBM Corporation and incorporated herein by 
cation key, a private key management key, or a private reference. , . . v t> 

user key can be specified to the GDS instruction only The Generate Device Authentication Key rair 
when the device is configured as an interchange device (GDAK) instruction generates a public and private 
(INTERCHANGE field in the configuration vector is authentication key pair, PUA and PRA. The generated 
BT) A device may act as both a certification center 10 keys are stored in the PUA buffer and PRA buffer in the 
and an interchange device. The GDS instruction exe- CF, respectively, as Crypto Facility PKA Key Record 
cutes only in the "run" state. 1 (CFPKR1) and Crypto Facility PKA Key Record 2 

FIG 9 is a flow diagram of a computer program and (CFPKR2). The 128-bit control vectors associated with 
method executed in device A to obtain public key certi- PUA and PRA are specified to the GDAK instruction 
fication. In FIG. 9, step 300 Begins the Device A Rou- 15 as inputs CI and C2, respectively. The contro vectors 
tine to Obtain Public Key Certification. specify the public key algorithm and other algorithm 

Step 302 begins the pre-init state and Loads IDa in related information necessary for key generation. Con- 
Device A. This uses the Load Physical Identifier sistency checking is performed on control Y ec | or s CI 
(LP1D) instruction which is described in the copending and C2. For example, the ALCWRITOM, A h~°' 
patent application by S. M. Matyas, et al., "Public Key 20 RITHM EXTENSION, and LENGTH fields in CI and 
Cryptosystem Key Management Based on Control C2 must match. Execution of the GDAK instruction 
Vectors " Ser No. 07/766,260. filed Sep. 27, 1991, as- causes the GDAK FLAG in the state vector to be set to 
signed to IBM Corporation and incorporated herein by the "full" state from the "empty" state. The instruction 
reference executes only when the GDAK FLAG is m the 

The Load Physical Device ID (LPID) instruction 25 "empty" state. (Note that the EPS instruction must be 
permits a 128-bit physical identifier of a device to be executed to reset the GDAK FLAG to the "empty" 
loaded into the CF and stored in the DID and EID state.) The GDAK FLAG serves two purposes: (a) it 
registers Execution of the LPID instruction causes the controls execution of the GDAK instruction, and (b) it 
DID flag to be set to the "full" state. The instruction indicates when the PUA and PRA buffers have been 
executes only when the DID flag is in the "empty" 30 initialized. The GDAK instruction executes only in the 
state. (Note that an EPS instruction must be executed in "preinit" state 

order to reset the DID flag to the "empty" state.) The Step 306 of FIG. 9 exports device A s public authenti- 
DID flag serves two purposes: (a) it controls the execu- cation key PUAa and IDa and Transfers them to the 
tion of the LPID instruction, and (b) it indicates Certification Center. This step uses either the ECFAR 
whether the DID and EID registers have or have not 35 instruction previously discussed, or alternately, the 
been initialized. The value of P1D stored in the DID Export Public Key (EPUK) instruction which is de- 
register is the PID value associated with PUA and PRA scribed in the copending patent application by S. M. 
(i e., the PUA and PRA of that device). The value of ■ Matyas, et al, "Public Key Cryptosystem Key Manage- 
PID stored in the EID register is used for two purposes: ment Based on Control Vectors," Ser. No. 07/766,260, 
(a) it is the value stored in the EIDO field of a certifi- 40 filed Sep. 27, 1991, assigned to IBM Corporation and 
cate and thus identifies the device to another device, incorporated herein by reference. The certification cen- 
and (b) it is the value stored in a DEA key record, ter must be sure that PUAa belongs to device A. This 
which is used by the GKSP and IDK instructions as an can be accomplished by removing PUAa from device A 
anti-reimport value. The 16 byte PID consists of an while it is still at the manufacturer's facility, and then 
eight byte network part and an eight byte riode part. 45 delivering PUAa to the certification center in a j secure 
The eight byte node part uniquely identifies the node manner, for example by courier. Alternately, PUAa can 
within a network. The eight byte network part uniquely be sent by device A over a link with integrity to the 
identifies the network. The objective is to arrive at a certification center and a later on-site physical audit can 
naming convention that will ensure unique PID values be performed to confirm that PUAa belongs to device 
from one network to another. One possibility is for the 50 A, this being a less secure method until the event of 
eight byte network part to be registered (e.g., with a on-site auditing has taken place. Alternately, the device 
registration center). The ECFAR instruction can be A can be delivered from the manufacturer to a third 
used by CFAP to read the contents of the DID and party who removes the PuAa key from the device and 
EID registers. For reasons of security, the LPID in- delivers it with integrity to the certification center, 
struction is architected such that the DID register con- 55 The Export Public Key (EPUK) instruction (1) trans- 
tents cannot be changed without erasing the contents of lates an Internal Key Unit containing public key PU to 
the PUA and PRA buffers (i.e., a different PID can't be an External Key Unit containing PU (PU-mode=0) or 
assigned to the same key pair stored in the PUA and (2) constructs an External Key Unit for the internally 
PRA buffers). In like manner, the ICFER instruction is stored key PUA (PU-mode= 1). The Export Public 
architected such that the EID register contents cannot 60 Key instruction has options for outputtmg the con- 
be changed without reinitializing the CKMP register structed External Key Unit (1) without a digital signa- 
with a new key. Otherwise, use of the EID buffer as an ture (PR-mode=0), (2) with a digital signature gener- 
anti-reimport value would be ineffective. The LPID ated with a PR supplied to the Export Public Key in- 
struction executes only in the "preinit" state. struction (PR-mode=2), or (3) with a digital signature 
Step 304 of FIG. 9 Generates public and private 65 generated with the internally stored key PRA (PR- 
authentication keys PUAa,PRAa in Device A and mode =3). The private key PR used with PR-mode =2 
Stores them in the cryptographic facility. This is carried can be a PRC, PRM, or PRU key. However, to gener- 
out by the Generate Device Authentication Key Pair ate a digital signature with private key PRC, the device 
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must be configured as a certification center (i.e., CER- 
TIFICATION = BT must be specified in the configu- 
ration vector). A hash-rule parameter indicates to the 
EPUK instruction the hash algorithm to be used in 
generating the digital signature. Control vectors CI, 5 
C3, and C4 are all associated with the PU to be ex- 
ported. CI is stored either in IKU1 (PU-mode=0) or in 
the PUACV register (PU-mode= 1). C4 is stored in 
EKU3, and C3 is an intermediate value used by the 
CFAP to request changes to CI, as follows. When a PU 10 
is exported, the CFAP is permitted, in certain cases, to 
change control vector fields. If no change is desired or 
no change is permitted, then the CFAP sets C3=C1, 
else the CFAP produces C3 by making selected 
changes to CI. The control vector checking process 15 
assures that C3 is properly specified. Likewise, when a 
PU is exported the CF is permitted to change certain 
control vector fields. If no change is needed or pre- 
scribed, then the CF sets C4=C3; else the CF produces 
C4 by making selected changes to C3. 20 

Step 308 of FIG. 9 begins the init state, loads the 
Configuration Vector received from the Certification 
Center and automatically requires the erasure of the 
existing master key KM in Device A. This step uses the 
LCV instruction described above. The LCV instruction 25 
automatically erases the existing master key KM. With 
no master key available, any other keys stored in device 
A in an encrypted form under the master key, will be 
unrecoverable. As a result of this step.308, the configu- 
ration vector is decoded and the cryptographic facility 30 
in device A is configured to conform to the security 
policy dictated by the certification center. 

Step 310 of FIG. 9 begins the run state and generates 
or loads a new master key KM in Device A. One of the 
security requirements of the configuration vector is 35 
specifying how the new master key is installed in device 
A. For example, the manual loading of a new master 
key is attributed as having less security than the autono- 
mous generation of a new master key from an internal 
random number generator in device A. The methods 40 
allowed for installation of the new master key in device 
A are dictated by the new configuration vector, which 
has encoded in it the security policy for the network 
established by the certification center. 

Step 312 of FIG. 9 imports the public certification 45 
key PUC into device A from certification center. This 
step uses the Import Public Key (1PUK) instruction 
described in the copending patent application by S. M. 
Matyas, et ah, "Public Key Cryptosystem Key Manage- 
ment Based on Control Vectors," Ser. No. 07/766,260, 50 
filed Sep. 27, 1991, assigned to IBM Corporation and 
incorporated herein by reference. PUC will be used by 
device A to validate the digital signature of the public 
key certificates device A receives from other devices, 
such as device B, in the network. 55 

Step 314 of FIG. 9 generates the public and private 
key management keys PUMa,PRMa in Device A and 
encrypts them as e*KM.Hl(PRMa) and e*KM.H2- 
(PUMa) respectively, and stores them in the crypto- 
graphic key data set (CKDS). This step uses the Gener- 60 
ate Public and Private Key Pair (GPUPR) instruction 
described in the copending patent application by S. M. 
Matyas, et al„ "Public Key Cryptosystem Key Manage- 
ment Based on Control Vectors," Ser. No. 07/766,260, 
filed Sep. 27, 1991, assigned to IBM Corporation and 65 
incorporated herein by reference. HI and H2 are hash 
values of the control vectors for the two keys. Alter- 
nately, PRMa and/or PUMa can be stored within the 
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secure boundary of the cryptographic facility of device 
A, in which case when a new configuration vector is 
loaded into the cryptographic facility, PRMa and 
PUMa will be erased. 

Step 316 of FIG. 9 sends a request 168 for registration 
of PUMa to certification Center including PUMa, IDa, 
CV, and Other control information. In the preferred 
embodiment of the invention, the request made by de- 
vice A for certification of its public key PUMa is done 
by sending PUMa 175, IDa 119, the control vector CV 
176, and other information 177' with the request 168 in 
a first transmission to the certification center. The 
EPUK instruction can be used for this step, as described 
above. 

Step 318 of FIG. 9 receives the random number 
nonce 171 from the certification center. This number is 
intended to be used as a nonce in the request/response 
protocol to guarantee freshness of the Audit record. 
The Certification Center generates a random number 
and sends it to the device to be audited in a Request-for- 
Audit message. 

Step 320 of FIG. 9 exports the audit record from 
device A, containing the configuration vector, nonce & 
IDa and a digital signature dSigPRAa on a hash value 
of the audit record using PRAa and transfers them to 
the certification center. The audit record 170 includes 
the configuration vector 161 copied from the CF envi- 
ronment memory 146' of device A, a random number 
nonce 171 sent from the certification center, and the 
identification IDa 119 of device A. This information can 
be referred to as the argument of the audit record. Ac- 
companying the audit record is the digital signature 
dSigPRAa 172 of a representation of the argument of 
the audit record, computed using the private authenti- 
cation key PRAa of device A. The representation of the 
argument upon which the digital signature is computed 
can be the entire argument or it can be a hash value of 
the entire argument. Digital signatures are computed 
using the Generate Digital Signature (GDS) instruc- 
tion, described above. 

Step 322 of FIG. 9 receives from certification center 
the PUMa certificate, including PUMa, IDa, CV, and 
other control information and a digital signature 
dSigPRC of a hash value of this information using the 
private certification key PRC. The PUMa certificate 
174 includes the public key PUMa 175 of device A 
which has been certified, the identification IDa 119 of 
the device A, the control vector 176 for PUMa, and 
other control information 177, which can include an 
indication of the level of security for device A, as speci- 
fied in its configuration vector 161. This information 
can be referred to as the argument of the certificate. 
Also included as a part of the certificate is the digital 
signature dSigPRC 178 of a representation of the argu- 
ment of the certificate, computed using the private cer- 
tification key PRC of the certification center. The rep- 
resentation of the argument upon which the digital 
signature is computed can be the entire argument or it 
can be a hash value of the entire argument. Digital 
signatures are computed using the Generate Digital 
Signature (GDS) instruction. 

Step 324 of FIG. 9 ends the routine to obtain public 
key certification at device A. 

Step 326 of FIG. 9 is shown to illustrate the normal 
use by device A of its certified public key, transmitting 
the PUMa certificate and its dSigPRC digital signature 
to another device in the network, such as device B. 
Device B will validate dSigPRC with device B*s Copy 
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of of the public certification key PUC. Each recipient of 176, and other control information 177 . This step uses 

a certified public key PUMa from device A is assured of the IPUK instruction described above. 

the genuineness of that key, that is the certificate and Step 412 of FIG. 10 generates the random number 

digital signature dSigPRC issued by the certification nonce 171 and transfers it to device A. 

center 10 on that key PUMa can be used by device B, 5 Step 414 of FIG. 10 receives the audit record 170 

for example, as proof that that key PUMa belongs to including the configuration vector 161 the nonce 171 

device A. Device B decodes the digital signature and IDa 119 and the digital signature dSigPRAa 172 

dSigPRC with his copy of the certification center's generated on a hash representation of the audit record 

public key PUC. to validate PUMa. But in accordance using PRAa 

with the invention, device B gains the additional knowl- 10 Step 416 of FIG. 10 authenticates that *e m*i 

edge that device A has adhered to the network security cord 170 is from device A. using PUAa to decrypt 

policy dictated by the certification center. This is con- * 72 " ^ ste P 11565 the VDS ™ tructlon 

firmed if device A has signed ^u^to^M ^^FIG. 10 verifies the audit record 170 by 

with a digital signature such as ^£^^^e P of the original configuration vec- 

A does not have the use of his P™^ « xh l™£% tor sto g re d in the certification center 10 with the copy of 

uration vector has been changed in device A. The leve conflguralion vec tor 161 received in the audit re- 

of security to which device A currently complies is 8^ A 

known to device B trough the other control ^forma- ^ Qf HQ> . f ^ ^ n was succcss . 

tion 177 which is a part of the PUMa certificate 174 of certification center will assemble the certificate 

FIG. 8. If the level of security to which device A cur- including PUMa 175, IDa 119, CV 176, Other 

rently complies is not sufficient for the purposes of m an(J the digha] signature dS i gP RC 178 gen- 

device B, device B can reject the PUMa public key and emtd Qn g ^ repr esentation of this information using 

not transmit its secret messages to device A until device pRC lg9 and wjU transfer it t0 device A< xhig step uses 

A can demonstrate that it has complied with a sufficient J$ hg EpTJK instruction described above, 

security level by sending another public key certificate Finally, step 422 of FIG. 10 ends the routine, 

signed with device A's digital signature using one of F1G n u a flow diagram c f a computer program and 

device A's private keys. Validation of digital signatures metno d executed in device A to perform key manage- 

is performed using the Verify Digital Signature (VDS) mem functions in the run state. Step 500 of FIG. 11 

instruction described in the copending patent applica- 3Q b egms dev ice A routine to perform key management 

tion by S. M. Matyas, et al., "Public Key Cryptosystem f unctions . 

Key Management Based on Control Vectors Ser. No. S tep 502 of FIG. 11 receives a ciphertext message 

07/766,260, filed Sep. 27, 1991, assigned to IBM Corpo- from anot her device B, encrypted under device A's 

ration and incorporated herein by reference. certified public key PUMa. 

The Verify Digital Signature (VDS) instruction veri- 35 s tep 504 0 f FIG. 11 accesses the previously en- 

fies a system signature, called dSig, in accordance with cryp ted private key, e*KM.Hl(PRMa) from crypto- 

Section 7 of ISO DIS 9796, where dSig was created gra phic key data set, stored there in step 314 of FIG. 9. 

from a Crypto Facility System Signature Record Step 506 of FIG. 11 recovers the private key PRMa, 

(CFSSR) in accordance with Section 6 of ISO DIS by decrypting with the exclusive OR product of the 

9796. The CFSSR is a CF-generated record containing 40 mas t e r key KM and the hash value HI. 

a 128-bit hash value calculated on a variable length step 508 of FIG. 11 decrypts the ciphertext message 

input data record, called data. CFSSR is recovered us j ng private key PRMa. 

from dSig by encrypting dSig with a public key, per- step 510 of FIG. 11 ends the routine, 

forming consistency checking on the recovered block, j t should be noted that the successful decryption of 

and discarding redundant data and extracting CFSSR. 45 the ciphertext message depends on the availability to 

There are no restrictions on the key type of the public device A of the master key KM, which must be used to 

key that may be used with the VDS instruction. The recover the private key management key PRMa. 

VDS instruction executes only in the "run" state. FIG. 12 is a flow diagram of a computer program and 

FIG. 10 is a flow diagram of a computer program and method executed in device A to change the configura- 

method executed in the certification center 10, to en- 50 tion vector. Step 520 of FIG. 12 begins the device A 

force network security policy. The steps in FIG. 10 for routine to change the configuration vector, 

the certification center are complementary with the Step 522 of FIG. 12 assembles a new configuration 

steps described above for device A in FIG. 9. Step 400 vector in a working register in device A. Device A is 

of FIG. 10 begins certification center routine to enforce currently in the run state. 

network security policy. 55 Step 524 of FIG. 12 loads the new configuration 

Step 402 of FIG. 10 receives and stores the PUA 153 vector from the working register and, because this step 

and ID 119 for each device. This step uses the IPUK requires the execution of the LCV instruction in the init 

instruction described above. state, this step performs an automatic, required erasure 

Step 404 of FIG. 10 assembles the configuration vec- of the existing master key KM in device A. 

tor 161 for each device, stores and transfers it to each 60 Step 526 of FIG. 12 generates or loads a new master 

respective device. key KM* in device A, since the old master key KM has 

Step 406 of FIG. 10 generates PUC 157 and PRC 159. been erased in the previous step. Device A has resumed 

This step uses the GPUPR instruction described above. operating in the run state. 

Step 408 of FIG. 10 exports PUC 157 and transfers it Step 528 of FIG. 12 continues run state operations, 

to each device. This step uses the EPUK instruction 65 Note that now if step 528 branches to step 500 of 

described above. FIG, 11 to recover the private key management key 

Step 410 of FIG. 10 receives the registration request PRMa for the purpose of decrypting a received cipher- 

168 from device A, including PUMa 175, IDa 119, CV text message encrypted under device A's certified pub- 
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lie key PUMa, the decryption will fail, since device A 
can no longer recover its privacy keys. In this manner, 
the network security policy promulgated by the certifi- 
cation center is implemented and enforced. 

Although a specific embodiment of the invention has 5 
been disclosed, it will be understood by those having 
skill in the art that changes can be made to the specific 
embodiment without departing from the spirit and the 
scope of the invention. 

What is claimed is; 10 

1. In a data processing network which includes a first 
data processor coupled to a second data processor, said 
first data processor including a first cryptographic sys- 
tem and said second data processor including a second 
cryptographic system, a method for enforcing a net- 15 
work security policy, comprising steps of: 

encoding a network security policy in a first configu- 
ration vector at said first data processor and trans- 
mitting said first configuration vector to said sec- 
ond data processor; 20 

decoding said first configuration vector in said sec- 
ond data processor and configuring said second 
data processor in response thereto to implement 
said network security policy; 

storing a public certification key and a private certifi- 25 
cation key of a certification key pair at said first 
data processor and transmitting said public certifi- 
cation key to said second data processor; 

storing a public utilization key and a private utiliza- 
tion key of a utilization key pair at said second data 30 
processor; 

transmitting a request from said second data proces- 
sor to said first data processor to certify said public 
utilization key; 

transmitting a representation of said first configura- 35 
tion vector in an audit record from said second data 
processor to said first data processor; 

verifying said audit record in said first data processor 
and transmitting a certificate for said public utiliza- 
tion key to said second data processor, said certifi- 40 
cate including a digital signature produced by said 
first data processor using said private certification 
key; and 

impairing use of said private utilization key in said 
second data processor in response to storing a new 45 
configuration vector in said second data processor. 

2. The method of claim 1, wherein said data process- 
ing network further includes a third data processor 
coupled to said first and second data processors, said 
third data processor including a third cryptographic 50 
system, prior to said step of impairing use of said private 
utilization key, further comprising the steps of: 

transmitting said public certification key to said third 
data processor; 

transmitting said certificate with said public utiliza- 55 
tion key to said third data processor, said certificate 
including said digital signature produced by said 
first data processor using said private certification 
key; and 

validating said public utilization key at said third data 60 
processor using said public certification key to 
decrypt said digital signature. 

3. The method of claim 1, wherein said step of storing 
a public utilization key and a private utilization key of a 
utilization key pair at said second data processor, fur- 65 
ther comprising the steps of: 

storing a master key in said second cryptographic 
system; 
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storing a representation of a control vector in said 
second cryptographic system; 

forming an exclusive OR product of said master key 
and said representation of said control vector; 

encrypting said private utilization key using said 
product as an encryption key, forming an en- 
crypted private utilization key; and 

said step of impairing use of said private utilization 
key further comprising the step of altering said 
master key in response to storing a new configura- 
tion vector in said second data processor; 

said encrypted private utilization key being incapable 
of decryption in response to said altering said mas- 
ter key. 

4. The method of claim 1, wherein said step of impair- 
ing use of said private utilization key further comprises 
the step of: 

altering said private utilization key in response to 
storing a new configuration vector in said second 
data processor. 

5. The method of claim 1, prior to said step of trans- 
mitting said audit record, further comprising the steps 
of: 

storing a public authentication key and a private au- 
thentication key of an authentication key pair at 
said second data processor; 

transmitting said public authentication key to said 
first data processor; 

forming an audit digital signature on a representation 
of said audit record in said second data processor 
using said private authentication key; 

transmitting said audit digital signature with said 
audit record to said first data processor; and 

validating said audit record at said first data proces- 
sor using said public authentication key to decrypt 
said audit digital signature. 

6. The method of claim 5, prior to said step of form- 
ing an audit digital signature on a representation of said 
audit record, which further comprises the steps of: 

forming a random number nonce in said first data 
processor and transmitting said nonce to said sec- 
ond data processor in response to said request to 
certify said public utilization key; and 

transmitting said nonce with said audit record from 
said second data processor to said first data proces- 
sor. 

7. The method of claim 1, wherein said step of encod- 
ing a network security policy in a first configuration 
vector at said first data processor, further comprises the 
steps of: 

storing said first configuration vector in said first data 
processor; 

said step of transmitting said audit record from said 
second data processor to said first data processor, 
further comprises the step of including a copy of 
said first configuration vector in said audit record; 
and 

said step of verifying said audit record in said first 
data processor, further comprises the step of com- 
paring said first configuration vector stored in said 
first data processor with said copy of said first 
configuration vector included in said audit record. 

8. The method of claim 1, wherein said data process- 
ing network further includes a third data processor 
coupled to said first and second data processors! said 
third data processor including a third cryptographic 
system, which further comprises the steps of: 
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encoding a network security policy in a second con- 
figuration vector at said first data processor and 
transmitting said second configuration vector to 
said third data processor; and 

storing said first configuration vector and said second 5 
configuration vector in a table in said first data 
processor. 

9. The method of claim 8, which further comprises 
the steps of: 

decoding said second configuration vector in said 10 
third data processor and configuring said third data 
processor in response thereto to implement said 
network security policy; 

said implemented network security policy configur- 
ing a first level of security for said second data 15 
processor and configuring a second level of secu- 
rity for said third data processor, said first level 
being a lower security level than said second level. 

10. The method of claim 9, prior to said step of im- 
pairing use of said private utilization key, further com- 20 
prising the steps of: 

transmitting said certificate with said public utiliza- 
tion key from said second data processor to said 
third data processor, said certificate including a 
security indication of said first level of security at 25 
said second data processor; and 

rejecting said public utilization key at said third data 
processor in response to comparing said security 
indication from said certificate with said second 
level of integrity configured at said third data pro- 30 
cesser. 

11. The method of claim 1, which further comprises: 
said step of transmitting a request from said second 

data processor to said first data processor to certify 
said public utilization key, including transmitting 35 
said public utilization key; and 
said step of verifying said audit record and transmit- 
ting said certificate, including transmitting in said 
certificate said public utilization key accompanied 
by said digital signature formed using said private 40 
certification key. 

12. The method of claim 1, which further comprises: 
said step of transmitting a request from said second 

data processor to said first data processor to certify 
said public utilization key, including transmitting 45 
said public utilization key, a source identity value 
and a control vector for said public utilization key; 
and 

said step of verifying said audit record and transmit- 
ting said certificate, including transmitting in said 50 
certificate said public utilization key said source 
identity value and said control vector, accompa- 
nied by said digital signature formed using said 
private certification key. 

13. In a data processing network which includes a 55 
first data processor coupled to a second data processor, 
said first data processor including a first cryptographic 
system and said second data processor including a sec- 
ond cryptographic system, a method for enforcing a 
network security policy, comprising steps of: 60 

encoding a network security policy in a first configu- 
ration vector at said first data processor and trans- 
mitting said first configuration vector to said sec- 
ond data processor; 

decoding said first configuration vector in said sec- 65 
ond data processor and configuring said second 
data processor in response thereto to implement 
said network security policy; 



storing a public utilization key and a private utiliza- 
tion key of a utilization key pair at said second data 
processor; 

transmitting a request from said second data proces- 
sor to said first data processor to certify said public 
utilization key and a representation of said first 
configuration vector in an audit record; 
verifying said audit record in said first data processor 
and transmitting a certificate for said public utiliza- 
tion key to said second data processor, said certifi- 
cate including a digital signature produced by said 
first data processor using said private certification 
key; and 

impairing use of said private utilization key in said 
second data processor in response to storing a new 
configuration vector in said second data processor. 
14. A computer program in a data processing net- 
work which includes a first data processor coupled to a 
second data processor, said first data processor includ- 
ing a first cryptographic system and said second data 
processor including a second cryptographic system, 
said computer program when executed, performing a 
method for enforcing a network security policy, com- 
prising the sequence of computer program instructions: 
encoding instruction for encoding a network security 
policy in a first configuration vector at said first 
data processor and transmitting said first configura- 
tion vector to said second data processor; 
decoding instruction for decoding said first configu- 
ration vector in said second data processor and 
configuring said second data processor in response 
thereto to implement said network security policy; 
first storing instruction for storing a public certifica- 
tion key and a private certification key of a certifi- 
cation key pair at said first data processor and 
transmitting said public certification key to said 
second data processor; 
second storing instruction for storing a public utiliza- 
tion key and a private utilization key of a utilization 
key pair at said second data processor; 
first transmitting instruction for transmitting a re- 
quest from said second data processor to said first 
data processor to certify said public utilization key; 
second transmitting instruction for transmitting a 
representation of said first configuration vector in 
an audit record from said second data processor to 
said first data processor; 
verifying instruction for verifying said audit record in 
said first data processor and transmitting a certifi- 
cate for said public utilization key to said second 
data processor, said certificate including a digital 
signature produced by said first data processor 
using said private certification key; and 
impairing instruction for impairing use of said private 
utilization key in said second data processor in 
response to storing a new configuration vector in 
said second data processor. 
15. A computer program in a data processing net- 
work which includes a first data processor coupled to a 
second data processor, said first data processor includ- 
ing a first cryptographic system and said second data 
processor including a second cryptographic system, 
said computer program when executed, performing a 
method for enforcing a network security policy, com- 
prising the sequence of computer program instructions: 
encoding instruction for encoding a network security 
policy in a first configuration vector at said first 
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data processor and transmitting said first configura- 
tion vector to said second data processor; 

decoding instruction for decoding said first configu- 
ration vector in said second data processor and 
configuring said second data processor in response 5 
thereto to implement said network security policy; 

storing instruction for storing a public utilization key 
and a private utilization key of a utilization key pair 
at said second data processor; 

transmitting instruction for transmitting a request 10 
from said second data processor to said first data 
processor to certify said public utilization key and 
for transmitting a representation of said first con- 
figuration vector in an audit record from said sec- 
ond data processor to said first data processor; 15 

verifying instruction for verifying said audit record in 
said first data processor and transmitting a certifi- 
cate for said public utilization key to said second 
data processor; 

impairing instruction for impairing use of said private 20 
utilization key in said second data processor in 
response to storing a new configuration vector in 
said second data processor. 

16. In a data processing network which includes a 
first data processor coupled to a second data processor, 25 
said first data processor including a first cryptographic 
system and said second data processor including a sec- 
ond cryptographic system, an apparatus for enforcing a 
network security policy, comprising: 

encoding means for encoding a network security 30 
policy in a first configuration vector at said first 
data processor and transmitting said first configura- 
tion vector to said second data processor; 

decoding means coupled to said encoding means, for 
decoding said first configuration vector in said 35 
second data processor and configuring said second 
data processor in response thereto to implement 
said network security policy; 

first storing means for storing a public certification 
key and a private certification key of a certification 40 
key pair at said first data processor and transmit- 
ting said public certification key to said second data 
processor; 

second storing means for storing a public utilization 
key and a private utilization key of a utilization key 45 
pair at said second data processor; 

first transmitting means coupled to said second stor- 
ing means, for transmitting a request from said 
second data processor to said first data processor to 
certify said public utilization key; 50 

second transmitting means coupled to said decoding 
means, for transmitting a representation of said first 
configuration vector in an audit record from said 
second data processor to said first data processor; 

verifying means coupled to said second transmitting 55 
means, for verifying said audit record in said first 
data processor and transmitting a certificate for 
said public utilization key to a certificate storage 
means in said second data processor, said certificate 
including a digital signature produced by said first 60 
data processor using said private certification key; 
and 

impairing means coupled to said decoding means, for 
impairing use of said private utilization key in said 
second data processor in response to storing a new 65 
configuration vector in said second data processor. 

17. The apparatus of claim 16, wherein said data 
processing network further includes a third data proces* 
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sor coupled to said first and second data processors, said 
third data processor including a third cryptographic 
system, which further comprises: 
third transmitting means coupled to said first storing 
means, for transmitting said public certification key 
to said third data processor; 
fourth transmitting means coupled to said certificate 
storage means, for transmitting said certificate with 
said public utilization key to said third data proces- 
sor, said 

certificate including said digital signature produced 
by said first data processor using said private certi- 
fication key; and 
validating means coupled to said third and said fourth 
transmitting means, for validating said public utili- 
zation key at said third data processor using said 
public certification key to decrypt said digital sig- 
nature. 

18. In a data processing network which includes a 
first data processor coupled to a second data processor, 
said first data processor including a first cryptographic 
system and said second data processor including a sec- 
ond cryptographic system, an apparatus for enforcing a 
network security policy, comprising: 

encoding means for encoding a network security 
policy in a first configuration vector at said first 
data processor and transmitting said first configura- 
tion vector to said second data processor; 
decoding means coupled to said encoding means, for 
decoding said first configuration vector in said 
second data processor and configuring said second 
data processor in response thereto to implement 
said network security policy; 
storing means for storing a public utilization key and 
a private utilization key of a utilization key pair at 
said second data processor; 
transmitting means coupled to said storing means, for 
transmitting a request from said second data pro- 
cessor to said first data processor to certify said 
public utilization key and for transmitting a repre- 
sentation of said first configuration vector in an 
audit record from said second data processor to 
said first data processor; 
verifying means coupled to said transmitting means, 
for verifying said audit record in said first data 
processor and transmitting a certificate for said 
public utilization key to said second data processor; 
impairing means coupled to said decoding means, for 
impairing use of said private utilization key in said 
second data processor in response to storing a new 
configuration vector in said second data processor. 

19. The apparatus of claim 18, which further com- 
prises: 

said transmitting means transmitting a request from 
said second data processor to said first data proces- 
sor to certify said public utilization key, including 
transmitting said public utilization key, a source 
identity value and a control vector for said public 
utilization key; and 
said verifying means verifying said audit record and 
transmitting said certificate, including transmitting 
in said certificate said public utilization key said 
source identity value and said control vector, ac- 
companied by said digital signature formed using 
said private certification key. 

20. The apparatus of claim 18, which further com- 
prises: 
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means for storing said first configuration vector in 

said first data processor; 
said transmitting means transmitting said audit record 
from said second data processor to said first data 
processor, including a copy of said first configura- 
tion vector in said audit record; and 
said verifying means verifying said audit record in 
said first data processor, by comparing said first 
configuration vector stored in said first data pro- 
cessor with said copy of said first configuration 
vector included in said audit record. 
21. In a data processing network which includes a 
first data processor coupled to a second data processor, 
said first data processor including a first cryptographic 
system and said second data processor including a sec- 
ond cryptographic system, a method for enforcing a 
network security policy, comprising steps of: 
encoding a network security policy in a first configu- 
ration vector at said first data processor and trans- 
mitting said first configuration vector to said sec* 
ond data processor; 
decoding said first configuration vector in said sec- 
ond data processor and configuring said second 
data processor in response thereto to implement 
said network security policy; 
storing a cryptographic key at said second data pro- 
cessor; 

impairing use of said cryptographic key in said sec- 
ond data processor in response to storing a new 
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by said first data processor using said private certi- 
fication key. 

23. A computer program in a data processing net- 
work which includes a first data processor coupled to a 
second data processor, said first data processor includ- 
ing a first cryptographic system and said second data 
processor including a second cryptographic system, 
said computer program when executed, performing a 
method for enforcing a network security policy, com- 
prising the sequence of computer program instructions: 

encoding instruction for encoding a network security 
policy in a first configuration vector at said first 
data processor and transmitting said first configura- 
tion vector to said second data processor; 

decoding instruction for decoding said first configu- 
ration vector in said second data processor and 
configuring said second data processor in response 
thereto to implement said network security policy; 

storing instruction for storing a cryptographic key 
said second data processor, 

impairing instruction for impairing use of said crypto- 
graphic key in said second data processor in re- 
sponse to storing a new configuration vector in said 
second data processor. 

24. In a data processing network which includes a 
first data processor coupled to a second data processor, 
said first data processor including a first cryptographic 
system and said second data processor including a sec- 
ond cryptographic system, an apparatus for enforcing a 



configuration vector in said second data processor. 30 network security policy, comprising: 



22. The method of claim 1, prior to said impairing 
step, which further comprises the steps of: 

storing a public certification key and a private certifi- 
cation key of a certification key pair at said first 
data processor and transmitting said public certifi- 35 
cation key to said second data processor; 

transmitting a request from said second data proces- 
sor to said first data processor to certify use of said 
cryptographic key; 

transmitting a representation of said first configura- 40 
tion vector in an audit record from said second data 
processor to said first data processor; 

verifying said audit record in said first data processor 
and transmitting a certificate use of saicj crypto- 
graphic key to said second data processor, said 45 
certificate including a digital signature produced 



encoding means for encoding a network security 
policy in a first configuration vector at said first 
data processor and transmitting said first configura- 
tion vector to said second data processor; 
decoding means coupled to said encoding means, for 
decoding said first configuration vector in said 
second data processor and configuring said second 
data processor in response thereto to implement 
said network security policy; 
storing means for storing a cryptographic key at said 

second data processor; 
impairing means coupled to said decoding means, for 
impairing use of said cryptographic key in said 
second data processor in response to storing a new 
configuration vector in said second data processor. 
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